Subject: Re: Threads References:X-Homemail: mailto:efp90@nuke.dircon.co.uk X-Url: http://www.users.dircon.co.uk/~nuke/ Resent-Message-Id: <"GcF1Q1.0.9c3.N1Thn"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/1437 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE X-Lines: 38 Status: RO Content-Type: text/plain Content-Length: 1507 Hi Adrian, > could someone explain how can MUI be used by application with > multiple threads. So far I know that one way is to have only one > thread talking to directly to MUI and other must use PushMethod > (which has its limitations). But I have two questions: > 1. Is it possible to create multiple MUI application object (one > for each thread) ? Yes, MetaTool is one example; the only drawback is that you can't use drag-and-drop etc. (at least not easily); for this reason my next program will use threads so offload sub-tasks rather than whole windows. > 2. Can the MUI Library pointer be shared ? Generally it's not a good idea to share any library base but... I've found it can... however I DO open muimaster.library from every task, I just share the pointer... maybe this isn't the same! > 3. The Amiga OS is multithread-safe (and so is BOOPSI ?). Why MUI > is not ? Errm, to do with RastPort's etc.? Only one task must render into an RP at a time... to make MUI fully Thread-Safe is do-able but would probably damage performance for all but the few applications which use it. Most other windowing systems aren't TS either; NeXTStep has extensive lightweight thread support but it's Objective-C system is not thread-safe by default; you can turn it on but it slows everything down by as much as 75% (NeXT figure), although Amiga Semaphores are considerably more efficient than NeXT/mach mutexes a bit of better design work would normally remove the need to do this altogether. Ellis. Subject: PushMethod crash To: mui@sunsite.Informatik.RWTH-Aachen.DE Resent-Message-Id: <"wzvoU2.0.Il2.vTcin"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/1470 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE X-Lines: 90 Status: RO Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 2511 Hi! In my project, I use several sub-processes that are dynamically created and disposed. I create my ApplicationObject in the main process, and that's also where I handle MUI's events (via standard loop). Main process runs with a priority of 0, sub-processes are at -1. I know that it is not possible to access MUI from different processes the same time, but I did it till yesterday for testing. It worked until more than one process was running. Okay, but I got my windows opened. Then I started to rewrite these functions with PushMethod, and my Amiga gurued. Why? I do something like this: ------- snip! ------- APTR GlobalApp; subtask_func() { ULONG Abort_Sortin; APTR BT_SortinCancel; APTR WI_Sortin; /* ... here I create WI_Sortin, BT_SortinCancel, and much more ... */ Printf("Let's go!\n"); Delay(50); if(WI_Sortin) { DoMethod(GlobalApp, MUIM_Application_PushMethod, BT_SortinCancel, 8, MUIM_Notify, MUIA_Pressed, FALSE, MUIV_Notify_Self, 3, MUIM_WriteLong, TRUE, &Abort_Sortin ); Printf("Notification set up...\n"); Delay(50); DoMethod(GlobalApp, MUIM_Application_PushMethod, GlobalApp, 2, OM_ADDMEMBER, WI_Sortin ); Printf("Member added...\n"); Delay(50); /* ... and so on ... */ } } main() { ... /* (standard loop) */ ... } ------- snap! ------- When I run this, I see the "Let's go", and then the sub-process crashes with a 80000004 - Illegal Instruction. Why? WI_Sortin was correctly initialized. Before I changed the DoMethod() to ...PushMethod, it worked. I will make this a custom class, but why does it crash? Subtask demo of MUI 3.3 seems to do it the same way: 343 DoMethod(data->app,MUIM_Application_PushMethod,data->self,2, MUIM_Class4_Update,100*(y+1)/FRACTALHEIGHT); So what's the difference? The next thing: I think that I can't use get() and set() no more from within my sub-processes. Is it correct to use these: #define pset(obj,attr,val) DoMethod(GlobalApp, \ MUIM_Application_PushMethod, obj, 3, MUIM_Set, attr, val) #define pget(obj,attr,ptr) DoMethod(GlobalApp, \ MUIM_Application_PushMethod, obj, 3, OM_GET, attr, ptr) ? And: How can I wait until the method was executed by the main process (I have to know when *ptr will contain the value)? Ciao, /Johnny/ from Cologne -- Subject: Re: PushMethod crash From: Thomas Ganter To: j.tevessen@line.org Date: Tue, 4 Jun 1996 12:37:40 +0200 Cc: mui@sunsite.Informatik.RWTH-Aachen.de (MUI Mailinglist) In-Reply-To: from "Johnny Tevessen" at Jun 2, 96 10:00:06 pm X-Mailer: ELM [version 2.4 PL25 ME8] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <96Jun4.123750met_dst.4892@sunbulirsch5.mathematik.tu-muenchen.de> Resent-Message-ID: <"pyZfV3.0.kq5.23Njn"@susi> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de X-Mailing-List: archive/latest/1482 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de X-Lines: 54 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 2257 [ Citation of Johnny Tevessen ] > Hi! > > [... answered in previous message ...] > > The next thing: I think that I can't use get() and set() no more > from within my sub-processes. Is it correct to use these: > > #define pset(obj,attr,val) DoMethod(GlobalApp, \ > MUIM_Application_PushMethod, obj, 3, MUIM_Set, attr, val) > #define pget(obj,attr,ptr) DoMethod(GlobalApp, \ > MUIM_Application_PushMethod, obj, 3, OM_GET, attr, ptr) > > ? And: How can I wait until the method was executed by the main > process (I have to know when *ptr will contain the value)? Both of the above would work, but you are right, you have no indication when the Method will have been invoked by MUI in the other TASK's context. And again, subclassing provides a solution. Simply write your own class (i.e. a sublass of application) and implement your own APPM_PushAndWait-method that could be invoked like the standard MUIM_Application_PushMethod. The, write your own APPM_PushAndWait to enqueue your Push-request and the current Task in a private list in your class'es custom data structure, then Wait() for some signal (perhaps CTRL-F, so that you can shut down your process in case of a bug). In your subclass'es dispatcher, simply check your private Push-list first. Process those first and then signal the Tasks with your magic Signal (you could of course also allocate a signalBit each time and enqueue it along with the Task and Method Data), dequeue the Pushed method afterwards. In case of a empty queue, process incomming methods by passing them to superclass (excluding APPM_PushAndWait of course :)). I hope this helps. -- - Thomas